Security alarm systems are well-known and have been around for decades. Some of the noteworthy large manufacturers of traditional security alarm systems are Honeywell, GE, DSC and Napco. These systems generally contain a low-power (i.e., 8-bit) processor, with no operating system, running small (i.e. tens or hundreds of kilobytes) embedded software. These security panels have a relatively compact and straightforward code base that is easily tested and maintained because updates to the embedded software are time-consuming and costly as they would require a new certification to be performed on the overall system and/or software before the deployment of the new code. Because of this, software updates are infrequent. These systems strive for the highest reliability possible and regulatory requirements often require them to pass stringent safety, reliability and fault tolerance tests before being allowed to be certified for sale to the public.
FIG. 23 is a block diagram of a security system panel of a conventional security system 2300 under the prior art. A security panel 2302 monitors and communicates with wired and/or wireless sensors 2304, and alarm conditions are reported to a Central Monitoring Station (CMS) via a phone line 2306. The security panel 2302 is coupled to an external power source 2310 (e.g., alternating current (AC) source, direct current (DC) source, etc.) and a battery 108, and the battery 2308 is generally trickle-charged by the panel 2302. The primary source of power for the security panel 2302 is the external power source 2310, and in the event of an interruption in the external power 2310, the panel 2302 automatically switches to the battery 108 as its power source.
Underwriters Laboratories® Inc. (UL) requirements dictate the minimum system performance required under battery operation. The UL certification is also required for the software residing on the conventional security panel 2302 in order to meet minimum safety and reliability performance levels. As such, software updates for conventional security panels occur very infrequently as they are costly and time consuming and involve highly-rigorous testing and regulatory certification.
Embedded monitoring, video and automation systems are also well known and have been around for some time. Due to the nature of their feature set they typically require larger processors and more sophisticated internal software to handle the more complex and bandwidth intensive operations. In addition, such systems are highly feature-rich and manufacturers are continually improving existing features and adding new ones in order to maintain their products competitiveness. As such, these systems often require software updates (either performed by the user or automatically performed in the background).
Creating a feature-rich system that combines both traditional security as well as consumer-oriented interactive features results in a product that is a superset of the two systems in terms of processing power and software. Consequently, when providing extended monitoring and automation features on top of such a security system, additional processing power and software is required. A larger code base inherently makes the overall system less reliable thereby making the reliability requirements imposed by security companies and security standards an even more challenging hurdle. The additional software inherently reduces the reliability of the overall code and introduces more software code paths that can potentially fail. This can also be a disadvantage as it can require the entire system to go through a security certification process each time the system software is modified, even if the software changes are only related to the interactive and consumer-related portion of the code. Furthermore, the battery backup of this integrated system, including the larger processor and memory, would require a larger battery and potentially more sophisticated backup circuitry for supporting the larger power load.